Deployment of maintenance packages to computing platforms often require downtime of such platforms. At the beginning of downtime, a backup is created and this backup serves as a fallback option, in case the upgrade fails. Advancements in technology have enabled for reduced, and in some cases, zero downtime upgrades. With such arrangements, upgrades run in parallel to a production system within the same database for the complete duration of the upgrade. The procedure creates clones of the tables, which are changed by the upgrade and runs database triggers to replicate data from production to the upgrade copy of the tables. With the maintenance procedure running in parallel with the production system in the same database, the upgrade can no longer be revoked by restoring a backup.
A restore of a backup is usually done as a point-in-time recovery: the full backup is restored, then the re-do-logs of the changes done to the system between the point in time of the full backup and the point in time, the administrator wants to restore are rolled forward. Such restores can only be run for the complete database.
If the upgrade runs into a problem, which requires stopping the upgrade and returning to the software version which had been used before the upgrade, only parts of the database need to be restored, other parts of the database cannot be restored as a restore of the production part would result in data loss.